TIKA-4856: /unpack/thumbnail returns the document thumbnail with its metadata - #3096

  What the PR adds vs. what exists

  ┌───────────────────────────────────────────────────────────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
  │                         PR piece                          │                                               Existing equivalent                                                │
  ├───────────────────────────────────────────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ ThumbnailDefaults (built-in → server block → request,     │ parse-context section in tika-config.json (baseline, loaded by the forked worker from the same file) + the       │
  │ per-component merge)                                      │ multipart config part (runtime delta, overlaid in the worker)                                                    │
  ├───────────────────────────────────────────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ ?renderThumbnails=true query param                        │ sending the same parser blocks in the request's config part                                                      │
  ├───────────────────────────────────────────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ /unpack/thumbnail + ThumbnailSelector                     │ standard-unpack-selector already has includeEmbeddedResourceTypes — filter to THUMBNAIL/RENDERING on plain       │
  │                                                           │ /unpack                                                                                                          │
  ├───────────────────────────────────────────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ thumbnail-defaults top-level key + TikaJsonConfig change  │ not needed                                                                                                       │
  ├───────────────────────────────────────────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ PDFParserConfig.maxRenderedPages                          │ no equivalent — this is the one genuinely missing piece (without it, rendering only page 1 forces maxPages: 1,   │
  │                                                           │ which cuts the text too)                                                                                         │
  └───────────────────────────────────────────────────────────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

  So my recommendation: keep maxRenderedPages (+ its test, PDF2XHTML/PDFParser wiring — it's pure parser config, exactly your preferred vehicle), drop the endpoint, the query
  params, ThumbnailDefaults, and ThumbnailSelector, and turn the built-in defaults JSON into a documented recipe (server docs + the ticket). The recipe is the deliverable — it's
  what the contributor actually needed a central place for.

  Literal JSON

  Initialization time — tika-config.json on a server that should render thumbnails on every parse (the forked worker loads this same file, so it applies to all endpoints with no
  request cooperation):

  {
    "parse-context": {
      "pdf-parser": {
        "imageStrategy": "RENDER_PAGES_AT_PAGE_END",
        "maxRenderedPages": 1,
        "ocr": { "dpi": 96, "imageType": "RGB" }
      },
      "emf-parser": { "renderImage": true, "renderOnlyEmbeddedResourceTypes": ["THUMBNAIL"] },
      "wmf-parser": { "renderImage": true, "renderOnlyEmbeddedResourceTypes": ["THUMBNAIL"] }
    }
  }

  Parse time, scenario A — the contributor's search-indexing case (metadata + text + thumbnail in one parse). POST /rmeta/config, multipart parts file + config, config part:

  {
    "parse-context": {
      "pdf-parser": {
        "imageStrategy": "RENDER_PAGES_AT_PAGE_END",
        "maxRenderedPages": 1,
        "ocr": { "dpi": 96, "imageType": "RGB" }
      },
      "emf-parser": { "renderImage": true, "renderOnlyEmbeddedResourceTypes": ["THUMBNAIL"] },
      "wmf-parser": { "renderImage": true, "renderOnlyEmbeddedResourceTypes": ["THUMBNAIL"] }
    }
  }

  Parse time, scenario B — "just give me the thumbnail" (replaces /unpack/thumbnail). POST /unpack, config part:

  {
    "parse-context": {
      "pdf-parser": {
        "imageStrategy": "RENDER_PAGES_AT_PAGE_END",
        "maxRenderedPages": 1,
        "ocr": { "dpi": 96, "imageType": "RGB" }
      },
      "emf-parser": { "renderImage": true, "renderOnlyEmbeddedResourceTypes": ["THUMBNAIL"] },
      "wmf-parser": { "renderImage": true, "renderOnlyEmbeddedResourceTypes": ["THUMBNAIL"] },
      "standard-unpack-selector": { "includeEmbeddedResourceTypes": ["THUMBNAIL", "RENDERING"] },
      "unpack-config": { "suffixStrategy": "DETECTED", "outputFormat": "FRICTIONLESS",
                         "outputMode": "ZIPPED", "includeFullMetadata": true },
      "embedded-limits": { "maxDepth": 3, "maxCount": 20 }
    }
  }

Yes — there's a properly Tika-shaped home for it: ship the priority logic as an UnpackSelector implementation, registered as a @TikaComponent. That's exactly what the pluggable
  selector interface exists for, and the PR's own docs already point people there ("Custom EmbeddedDocumentExtractor is ignored; use UnpackSelector"). The contributor keeps his
  selection logic server-side, it's addressed purely by config name — and it gets something his endpoint never had: it works everywhere pipes UNPACK mode works, including
  tika-async-cli batch runs, not just one tika-server route.

  Concretely: a ThumbnailUnpackSelector next to StandardUnpackSelector in tika-pipes-core, encoding his priority (raster THUMBNAIL at depth 1 → RENDERING below a vector THUMBNAIL →
  first-page RENDERING), selecting at most one document. Parse time:

  {
    "parse-context": {
      "pdf-parser": { "imageStrategy": "RENDER_PAGES_AT_PAGE_END", "maxRenderedPages": 1,
                      "ocr": { "dpi": 96, "imageType": "RGB" } },
      "emf-parser": { "renderImage": true, "renderOnlyEmbeddedResourceTypes": ["THUMBNAIL"] },
      "wmf-parser": { "renderImage": true, "renderOnlyEmbeddedResourceTypes": ["THUMBNAIL"] },
      "thumbnail-unpack-selector": {},
      "unpack-config": { "outputFormat": "FRICTIONLESS", "outputMode": "ZIPPED",
                         "includeFullMetadata": true },
      "embedded-limits": { "maxDepth": 3, "maxCount": 20 }
    }
  }

  Result: a package containing exactly one image plus its metadata — functionally his {metadata, image} response, minus the bespoke route. Or baked into tika-config.json's
  parse-context for a dedicated thumbnail server with zero request config.

 {
    "presets": {
      "render-thumbnails": {
        "pdf-parser": { "imageStrategy": "RENDER_PAGES_AT_PAGE_END", "maxRenderedPages": 1,
                        "ocr": { "dpi": 150, "imageType": "RGB" } }
      },
      "our-archival-ocr": {
        "pdf-parser": { "ocr": { "strategy": "OCR_AND_TEXT_EXTRACTION", "dpi": 300 } }
      }
    }
  }

  (First block overrides a built-in by name — admin wins over Tika; second is a purely custom one.)

  Parse time — the reference lives in the config part, next to (and under) the request's own parse-context:

  { "presets": ["render-thumbnails"] }

  on POST /rmeta/text/config for his index request — metadata, text, and thumbnail in one parse. And the standalone "just give me a thumbnail, I don't care" case is POST /unpack
  with:

  { "presets": ["thumbnail"] }

  where thumbnail is a second built-in preset that bundles render-thumbnails plus the selection: thumbnail-unpack-selector (his ThumbnailSelector logic as an UnpackSelector
  component), unpack-config with Frictionless output, and embedded-limits. One image plus its metadata comes back; no /unpack/thumbnail route needed. A request can still layer its
  own overrides: {"presets": ["render-thumbnails"], "parse-context": {"pdf-parser": {...}}} — request wins, per component, which is exactly the layering semantics
  ThumbnailDefaults.applyTo already implements.

 {
    "presets": ["thumbnails"],
    "parse-context": {
       "pdf-parser": ...
     }
  }

PUT /tika/text/preset/render-thumbnails        body = document
PUT /rmeta/text/preset/render-thumbnails       body = document
PUT /unpack/preset/thumbnail                   body = document

/rmeta/text                →  /rmeta/preset/render-thumbnails/text
  /rmeta                     →  /rmeta/preset/render-thumbnails
  /tika/text                 →  /tika/preset/ocr-heavy/text
  /tika                      →  /tika/preset/ocr-heavy
  /unpack                    →  /unpack/preset/thumbnail
  /unpack/all                →  /unpack/preset/thumbnail/all